\section{Composant}
	\subsection{Au niveau M2}
		\addcontentsline{toc}{subsection}{Interface requise et fournie}
		\paragraph{\textit{Interface requise et fournie : \\}}
Les composants poss\' edant une interface des services et ports requis, et une autre des services et ports fournis, deux instances de la classe 'ComponentInterface' du modèle M2 ont donc été crées.
			\subparagraph{Utilsation des ports : la couche d'abstraction des services : \\}
Les composants doivent pouvoir accéder aux ports, mais uniquement via les services, ces derniers faisant donc offices de couche d'abstraction pour les composants.\\
On peut d'ailleurs en voir un exemple lors de la connexion du client au server, dans la classe exemple 'getDataExample'.
			\subparagraph{Attribution des ports aux services : pattern de d\' el\' egation :\\}
Puisque les services vont utiliser des ports (Voir M2) et que cette utilisation est diff\' erente selon l'interface de chaque composant, ceci est donc d\' efini au niveau du mod\` ele M1.\\
Ainsi, c'est la raison pour laquelle la classe 'ComponentInterface' est abstraite : la m\' ethode abstraite 'buildService' permet aux interfaces de composants du mod\` ele M1 (Et donc h\' eritant de 'ComponentInterface'.)  de d\' efinir elle-m\^ eme quels services vont utiliser tels ou tels ports.\\
Nous avons donc la démarche suivante : 
\begin{itemize}
\item{Les interfaces des composants sont donc d'abord instanciées,}
\item{Puis les instances de ports et de services leurs sont ajoutées,}
\item{Enfin, des ports sont attribués aux services correspondant via 'buildService'.}
\end{itemize}
		\addcontentsline{toc}{subsection}{Utilisation du mot-clef 'final'}
		\paragraph{\textit{Utilisation du mot-clef 'final' : \\}}
Afin de donner un mod\` ele M2 non-modifiable, puisqu'il s'agit d'un m\'eta-mod\` ele, toutes les m\' ethodes de celui-ci sont d\' eclar\' ees 'final' : le mod\` ele M1 impl\' ementant M2 ne pourra donc que s'appuyer, comme pr\' evu, sur celui-ci, et non le red\' efinir.
	\subsection{Au niveau M1}
		\addcontentsline{toc}{subsection}{Les singleton}
		\paragraph{\textit{Les singleton :\\}}
Actuellement, notre mod\` ele M2 ne repr\'esente qu'un seul client, avec un seul connecteur et serveur. C'est pourquoi leurs classes utilisent le pattern 'singleton'.\\
Cependant, nous pourrions \` a l'avenir faire \' evoluer cel\` a en retirant le singleton du client : un nouveau client pourrait alors se connecter, mais il faudrait en cons\' equence ajouter une gestion de l'acc\` es multiple aux r\^ oles du connecteur.

		\addcontentsline{toc}{subsection}{Les 'internal-bindings'}
		\paragraph{\textit{Les 'internal-bindings' : \\}}
Afin de lier un port à un autre au sein d'un composant, nous avons ajout\' e la notion de 'internal binding', correspondant ainsi \` a notre mod\` ele M2, indiquant qu'un composant est compos\' e de connecteurs.\\
Ainsi, un internal binding h\'erite de Binding, mais lie un port \`a un autre, au sein d'un m\^eme composant.
